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Abstract 


The design of a standalone battery powered Soft- 
ware Defined Radio (SDR) is presented. Three 
rounds of prototypes were designed, built, and 
tested over the last three years. The hardware ar- 
chitecture of the newest design is detailed, with 
the goal of getting the device into the field to 
build real RF links. The software stack, from 
the high-level websocket user interface down to 
the embedded Linux operating system are dis- 
cussed. Finally, the latest work on the Field Pro- 
grammable Gate Array (FPGA) modem are pre- 
sented, including optimization work that drasti- 
cally improves simulation performance. 
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1 Introduction 


In 2012 I reported my first success along the 
way of developing a new type of Software De- 
fined Radio[1]; one in which the whole SDR is 
contained in a single, portable unit. I was espe- 
cially inspired to do this for my love of backpack- 
ing, and I continually find myself in the position 
where I really want to have radio communica- 
tions available in places where today you can’t 
expect them. 

The dream, as Eric Blossom wrote in the ar- 
ticle Exploring GNU Radio[2], is to stretch the 
*smarts” of the Internet out from the cell towers 
to everyone’s smartphone. The belief which I still 
hold today, is that if we all carry around a base 
station, we will be well on our way to distributed 
and fault tolerant Internet access worldwide. I 
know that this is a lofty goal, but with the right 
tools we can begin to explore new frontiers in 
networking. 

My key goals for the project are to: 


e Design and build a standalone, software de- 
fined transceiver that works with commonly 
available Amateur radio modes. 


e Make it easy to use by providing connectiv- 
ity and extensibility layered on top of Open 
Source software. 


e Focus on small footprint and low power 
consumption to enable portable operation, 
much like with a cellular modem chipset. 


At the time I presented at the DCC 2012, I had 
never designed or laid out a radio circuit board 
before. I studied Computer Engineering at the 
University of Maryland, College Park, and I’ve 
loved ripping apart computers from a young age. 
Radio Frequency circuits are an entirely different 
beast, however. There’s a huge learning curve to 
building a SDR from scratch, and the remainder 
of this paper will detail the evolution of the de- 
sign, and the things which I learned along the 
way. 


2 Hardware 


2.1 Design Evolution 


The first pre-alpha design was completed thanks 
to the WIESEL laboratory at the University of 
Utah, and with the help of my good friend Aaron 
Schulman. Aaron at the time was finishing his 
PhD in Computer Science at University of Mary- 
land. I built the first transceiver by ordering de- 
velopment kits for all of the main integrated cir- 
cuits I wanted to use: a SoC FPGA!, a quadra- 
ture transceiver, a frequency agile VCO & PLL, 
and Analog to Digital / Digital to Analog con- 
verters. Plugging them all together, and getting 
access to a real RF lab, meant that I could build 
the proof-of-concept and make sure that the core 
idea was sound. 

Building a radio from discrete components 
turns out to be a difficult problem. The art 
of building a receiver is a complex and detailed 
one, full of tradeoffs between power, price, per- 
formance, size, and many other factors. Further- 
more, a core concern for me was that I needed 
to build a quality transmitter as well. This ulti- 
mately turned out to be the most difficult chal- 
lenge. 

The first custom board, Whitebox Alpha, was 
built at the University of Maryland, College 
Park, with the help of Aaron. The build oc- 
curred four months after the first time I presented 
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Figure 2: Whitebox Bravo 


the design at DCC 2012. I fabricated two 4- 
layer PCBs with Sunstone Circuits, and ordered 
parts from major distributors in the USA includ- 
ing Digi-Key and Mouser. I also ordered a sol- 
der paste stencil. Most of the components were 
on the top, so I solder-pasted the side and then 
carefully placed the components with tweezers. I 
used a hot plate to solder on the components. It 
worked quite well, except for the connector for 
the computer, which I had to have professionally 
put on to get a good connection. Ultimately, the 
computer worked on this design but the IF os- 
cillator was unable to lock reliably, due to me 
messing up the nets around the PLL Loop Filter 
and VCO’s tank circuit. 
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Figure 3: Whitebox Charlie 


Whitebox Bravo was built at a contract man- 
ufacturer (CM) in Carlsbad, CA, and I really 
enjoyed using the surface mount assembly line. 
This one came together around one year after 
the build of Whitebox Alpha. My goal here was 
to really focus on the core RF system and ver- 
ify that I could design a PCB that would radiate 
RF. The design had around 130 components on 
it, and I was able to get all of the PLLs to lock. 
I began to work on the full RF signal chain. A 
major problem that I had still at this point was 
that I had no RF test gear. In particular, if you 
plan to make a radio without a calibrated RF 
Signal Generator and RF Spectrum Analyzer, I 
wish you luck! Those tools are critical to under- 
stand the behavior of your creation. 


After a year of working on Whitebox Bravo, 
Bruce Perens K6BP started to acquire Boat An- 
chors and ship them my way to help me be able 
to understand the intricacies of the second pro- 
totype. The lessons were clear - the various sub- 
circuits need appropriate RF filtering to connect 
them together, and the transmitter needed addi- 
tional circuitry to calibrate it for spurious emis- 
sions requirements. Given that I could solve both 
of those problems, the device would be ready for 
serious amplification and to be used by others. 


Whitebox Charlie, was designed over a 7 
month time span starting directly after the DCC 
2014 Sunday Seminar that I did on FPGA 
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SoCs|5]. This board is a full five times more com- 
plicated than the previous design. The goal this 
time was to get the board off of my bench and 
into the field. It sits inside of a 160mm x 75mm 
extruded aluminum case from Hammond Mfg. I 
use U.FL connectors on every important RF net. 
I can always not stuff them after I’ve figured out 
the design issues. The fabricated PCB is 6 lay- 
ers and the additional two microstrip layers allow 
for a much more dense route while maintaining 
signal integrity for the critical RF traces. 


2.2 Baseband Subsystem 


The entire design received an overhaul based on 
the lessons learned from the previous prototypes. 

For power input, there is transient voltage sup- 
pression, reverse polarity protection, and high 
voltage filtering to condition the noisy signal 
coming from a car battery as it is charged via 
its alternator. Two on-board switching regula- 
tors provide efficient digital power at 3.3 and 
5 Volts for the embedded computer and its pe- 
ripherals. A wide input-voltage tolerant 5 Volt 
Low-Dropout Regulator (LDO) provides analog 
power, and a 3.3V regulator stems off of this 
for the analog circuits on the baseband. The 
analog portion of the board can be turned off 
from the microcontroller by setting a global En- 
able flag low. Wakeup times from this state 
should be on the order of 100ms. There are other 
standby modes available that trade wakeup times 
for static power dissipation. 

The System on Module contains the baseband 
embedded ARM Cortex-M3 and FPGA [3]. It 
is in a separate daughter card which plugs into 
the main board. The main reason to not place 
this component myself is to not have to deal 
with the 484 pin BGA package, in addition to 
the BGA packages for the on-board LPDDR 
RAM (64MBytes) and Flash (16MBytes). Rasp- 
berry Pi B+ 40-pin and 8-pin (mostly) compat- 
ible headers are available for custom expansion. 
You'll have to try individual boards to see if they 
fit, and to see if you can get the driver ported. 
I expect most WiFi, Bluetooth, GPS, and Au- 
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Figure 4: Baseband Subsystem Schematic 
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dio CODEC devices to work out of the box, but 
your mileage may vary. I maintain a official list 
of working devices in the codebase. 

The system module supports standard com- 
puter peripherals including USB On The Go 
(OTG) and 10/100 Ethernet. There are 6 LEDs 
on board covering RESET, Power, PTT, and 
three for user control. The RESET and PTT sig- 
nals also expose Open-Drain outputs so that way 
you can control much higher voltage equipment, 
like a 100W power amplifier and a T/R switch. 
The only externally exposed button is a RESET 
button, but there is a 100-mil header ready for 
you to tap in for Reset, PTT and dit-dah paddle 
inputs. All inputs are double-layer Electrostatic 
Discharge (ESD) protected for ruggedness. 


The clocking subsystem uses a_ high- 
performance, low phase noise 10MHz Tem- 
perature Compensated Crystal Oscillator 


(TCXO) to provide the main sampling clock 
for both the analog and digital sections of the 
mixed signal system. A clock buffer distributes 
the signal to the PLL reference inputs, as well 
as to the ADC and DAC. A transformer coupled 
external 1OMHz reference can be applied as well, 
and switched in by changing a jumper. 

The CODEC is the most important set of com- 
ponents for transceiver performance on the base- 
band side of the design. For this project I am 
building a quadrature sampling transceiver, so 
the ADC and DAC must be of the dual, simul- 
taneous sampling variety. This design features 
operational amplifiers at the inputs and outputs 
of the ADC & DAC respectively. The reason 
for this, which I did not understand for earlier 
designs, will be explained later in the section 
on overall system performance. A tradeoff must 
be made between sampling speed, sample reso- 
lution in bits, and power consumption. In this 
case, I chose a 10-bit ADC and am operating it 
at 1OMSPS. The DAC is also 10-bit, LOMSPS. 
We would ideally move to 12-bit models, but the 
oversampling does help somewhat for maintain- 
ing overall system dynamic range. 

An additional 8-channel auxiliary ADC is used 
to observe the following signals: transceiver tem- 
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perature, input power voltage, received signal 
strength, transmitter calibration signals, and 
PLL test points. An additional 4-channel aux- 
iliary DAC is used to calibrate the baseband 
transmit signal coming out of the communication 
DAC. The objective of this circuit is to minimize 
local oscillator feedthrough. The transmitter cal- 
ibration routine will be described in more detail 
in the next section. 


2.3. RF Subsystem 


The RF portion has its own power tree to iso- 
late the subsystems as much as possible. Numer- 
ous rails are required, and LDO’s were chosen for 
low noise and high Power Supply Rejection Ra- 
tio (PSRR). There’s a 3V rail for the Low Noise 
Amplifier, a 3.3V Rail for the VCO’s, and a sep- 
arate 3.3V regulator for the rest of the analog 
subsystems. A 1.8V LDO supplies current to the 
RF Gateway. 

The RF Gateway is a simple SPI slave designed 
in acheap CPLD from Xilinx. The gateway talks 
to the main computer via SPI, and then con- 
trols the various RF and amplifier switches. This 
turned out to be cheaper than using discrete logic 
gates, and is safer than using just GPIOs. For 
example, it’s not possible to turn on the Power 
Amplifier when receiving, thus reducing the like- 
lihood of blowing the amplifiers. 

Due to the superheterodyne architecture of 
the quadrature transceiver, two local oscillators 
are needed. The first oscillator works with the 
quadrature modulator & demodulator to go from 
the fixed Intermediate Frequency of 9OMHz down 
to baseband. Since this oscillator’s frequency 
never changes, it’s Loop Filter is optimized to 
trade lock times for reduced phase noise. 

The second oscillator works with both the re- 
ceiver’s mixer, as well as the transmitter’s im- 
age reject up converter. This oscillator has 
very demanding requirements. It needs fine fre- 
quency resolution, fast lock times, and low phase 
noise. These conflicting requirements means that 
a tradeoff has to be made. Both oscillators have 
available U.FL connectors so a new oscillator can 
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Figure 5: RF Subsystem Schematic 
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be plugged in depending on the application. 

The core transceiver chip comes from CML 
Microsystems|4]. This transceiver has a very de- 
tailed manual and I’ve read it more times than I 
care to admit. There are many features of this 
chip and I will explore some of them later when 
we get to talking about the integrated design. 

Between the core transceiver and the antenna 
jack, there sits a lot of additional RF circuitry 
that was not in the Bravo design. On the trans- 
mit side, after the signal leaves the transceiver 
chip, it flows into one of four bandpass filters in a 
selectable filter bank. The goal is to cut out spu- 
rious emissions that leak in from the harmonics 
of both oscillators. 

After filtering, the to be transmitted signal can 
be sent down two paths: the first is to the power 
amplifier (20dBm maximum output) on the way 
to the antenna, while the second path goes to 
a RF log detector. The Log Detector is used to 
measure the signal strength of spurious emissions 
and is used to calibrate the transmitter’s oscilla- 
tor leakage and undesired-sideband suppression. 

For the receiver, a switch lets you choose be- 
tween two different signal sources. One comes 
from the transmit-receive switch, while the other 
comes from a built-in RF noise source. The noise 
source is built using an avalanche diode that is re- 
verse biased very close to its breakdown voltage. 
The output of this signal is amplified and pre- 
sented to the receiver chain as a self-test feature. 
Whichever receive signal is chosen, it then flows 
through the onboard bandpass filter bank and 
into an LNA. The LNA provides 14dB - 20dB of 
gain depending on the frequency. The final step 
as an RF signal is through a matching network 
on the way into the transceiver chip’s mixer. 


2.4 System Performance 


A very important step, which was accomplished 
early in the Carlie design phase, was to do a full 
RF System analysis. The goal here is to start to 
look at how the transceiver would operate in a 
real RF link. An important thing to remember 
while reading this section is that when we talk 
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about RF signals, we really want to talk about 
power, and not in terms of voltage, current and 
resistance. So put aside Ohm’s Law for the mo- 
ment (though don’t forget it!) and remember the 
power laws P= IV = V?2/R=TI°R. Also, we'll 
be using decibels everywhere, so we can just add 
the power terms together to get overall system 
power. 

For the receiver, a signal is present at the an- 
tenna of lets say -110dBm at 50 Ohms. First, the 
signal flows through the T/R switch, the receiver 
signal switch, and the bandpass filter, which at- 
tenuates the signal by 6.2 dB, bringing it down 
to -116.2dBm. Next, the LNA is applied. The 
LNA provides 15 dB of gain, bringing the signal 
back up to -101.2dBm, while only increasing the 
noise by 0.6 dB. 

The next sections of the receiver chain are fo- 
cused around the transceiver chip. A 1:1 trans- 
former balun and matching network brings the 
impedance up to 300 Ohms to be matched to the 
mixer. Its after this mixer stage that one of three 
possible bandpass filters can be selected: 1MHz, 
100kHz, or 30kHz. The selected filter bandwidth 
plays an important role on the final Signal to 
Noise ratio as seen after the quadrature demod- 
ulator. This is because the narrower the IF filter, 
the less noise power that makes it through to the 
ADC. 

Now comes an important step which I did not 
include in the Bravo design - there is an opera- 
tional amplifier between the quadrature demodu- 
lator and analog to digital converter. I didn’t see 
the purpose at first, but now I know the goal of 
the Op Amp is to increase the signal power. For 
example, if the input impedance of the OpAmp 
is 100kOhm, and the output impedance is 50 
Ohm, and the voltage gain is set to 1x (or 0dB), 
there is actually a power gain of 33dB due to 
the impedance transformation through the volt- 
age follower. 

Overall, the receiver into the computer has a 
computed Noise Figure of 6dB and has sensitivity 
down to -110dBm, while consuming less than one 
Watt. 

For the transmitter, the output of the Dig- 


ital to Analog converter is 1 mA into a 400 
Ohm resistor, or around -4dBm. There is an 
LC based lumped element filter followed by an 
OpAmp that conditions the signal leading into 
the transceiver chip. The image-reject up con- 
verter has a characteristic impedance of 200 
Ohms, and on the way out a 4:1 balun is used 
to match the signal back to 50 Ohms at -10dBm. 
The signal attenuates 5dB as it goes through the 
bandpass filter bank. Next, two amplifier gain 
stages are applied to raise the signal up 15 and 
then 20 dB, resulting in a final signal strength of 
20dBm, or 100mW at the antenna jack. 


3 Software 


3.1 User Interface 


The user interface is your smartphone or tablet. 
My original dream was to have the smartphone 
interface be inside of the device, but it doesn’t 
make sense yet to integrate it all. Step by step 
we can get there, but it’s too complex for Charlie. 
Your device can be plugged into the USB OTG 
port and charged with the on-board 5V regula- 
tor, so they are good companions. 

Android/iOS can be interfaced via USB OTG 
or WiFi/Bluetooth if you attach the right add-on 
to the Whitebox. Since I’ve started this project, 
a number of high quality Applications have been 
ported and implemented. AprsDroid [6] is a 
nice interface to APRS. Sound card support is 
available today, but the Bluetooth TNC or TCP 
modes should be possible to interface with di- 
rectly given some hacking. 

FLDigi [7] was ported recently and can be sup- 
ported out of the box. This adds a lot of modes 
including MFSK, BPSK, PSK, OLIVIA, THOR, 
DOMINOEX, and MT63. All of these modes are 
supported at various standard baud rates. 

There’s no reason to not see the rest of the pop- 
ular digital modes, like JT65 [8] ported. There’s 
hope of getting FreeDV [9] and other digital voice 
modes via the Digital Voice Server [10]. I would 
really like to see CHIRP [11] ported to Android 


with some kind of universal USB programmer. 
Whitebox support would be neat, too. 

There’s lots of fun projects for smartphones, 
and when we do end up with the touch screen 
inside of a Whitebox, all of it will work natively. 
So if these kinds of projects interest you, go for 
it! 


3.2 Internal Software Stack 


From the top of the software stack, the device 
looks like a web server over a network connection. 
Bruce K6BP has been contributing to the project 
with the Algoram websocket server (checked into 
the main codebase[12]._ He ported websockets 
and cJSON to the embedded platform. There’s a 
full responsive UI for controlling the transceiver, 
as well as a web service API. The JavaScript sup- 
ports the WebAudio API and you can control 
the transceiver right from Chrome on Android 
devices. 

Available options for the receiver include a 
checkbox to turn on/off the LNA; 0dB - 48dB of 
attenuation in 6dB increments; a button to run 
the receiver calibration. The transmitter is sup- 
ported with a checkbox to turn on/off the Power 
Amplifier, and a button to run the transmitter 
calibration. Both transmit and receive can select 
the appropriate bandpass filter. There are visual 
indicators for the transceiver temperature, input 
voltage, received RSSI, and PLL lock status. 

The transceiver is controlled by the white- 
box library. This provides the verbs and nouns 
needed to control the transceiver. Things like 
‘whitebox_tx’ starts a transmission, and ‘white- 
box_write’ writes data out to the transmitter. 
Conversely, ‘whitebox_rx’ starts a receive, and 
‘whitebox_read’ reads data out of the receiver. 
There’s also data structures and methods to con- 
trol modems exposed from the FPGA. 

Linux is the common denominator of the in- 
ternal Whitebox software stack, and it provides 
a plethora of features. We even get the AX.25 
stack for free, built right into the OS. 

The kernel interfaces with all of the hardware 
via drivers, including a custom driver that con- 
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trols the digital signal processing which happens 
in the FPGA, which will be discussed at the end. 


The driver is zero memory copy, utilizing 
mmap to share memory between user space and 
the driver. A circular buffer is used to transport 
data between memory to peripherals, peripher- 
als to memory, and memory to memory with the 
Direct Memory Access Controller (DMA). 


For connectivity, as mentioned earlier, both 
USB OTG and 10/100 Ethernet are available. 
USB OTG is probably the most interesting for 
expanding the Whitebox. I ported ALSA to the 
device, and USB sound cards work great in USB 
host mode. So does WiFi, Bluetooth, and GPS 
USB dongles. 


Linux also includes a Gadget driver interface, 
and you can expose the Whitebox to your PC 
as a full USB peripheral. The same cable can 
support a sound card, a command line shell, a 
networking interface, and many more; all at the 
same time. 


I find the Ethernet to be invaluable while I 
develop. You can mount your laptop over NFS to 
do quick and iterative development. You can also 
flash the operating system over Ethernet. The 
FPGA & bootloader can be programmed from 
the Ethernet too, though I have not finalized the 
utility for this yet. 


A bricked device can be recovered via a JTAG 
header, though you do need a custom program- 
mer for now. BusPirate support is coming, but it 
depends on Actel targeting the SVF file format 
for the SmartFusion2... they say it is “Coming 
Soon”. 


The FPGA toolchain is free, if you sign up with 
Microsemi. It supports a big enough FPGA to 
have a few transceivers in one. It (apparently) 
works on RHEL Linux, though I usually use it 
on Windows. You won't have to mess with that 
stuff though unless you want to play with the 
digital signal processing chain. 
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4 Firmware 


Since the Whitebox is a quadrature transceiver 
SDR, an important process that happens in the 
baseband modem is to convert from software 
data, like audio or binary payloads, to a base- 
band signal. The baseband signal is a quadra- 
ture signal, meant to be sent through a quadra- 
ture modulator or captured from a quadrature 
demodulator. 

To transform between the software and base- 
band signals, we need a modem. This modem 
sits in the FPGA and consists of two main parts: 
the digital signal converter, and the modula- 
tors/demodulators. All of them are digital signal 
processing flowgraphs. 

The digital signal converter moves from a low 
sample rate baseband signal, to a high sam- 
ple rate baseband signal. The signal is rate- 
converted with a CIC filter, and then passes 
through a quadrature mixer for fine tuning. The 
quadrature mixer is based on complex multiplies 
instead of CORDIC, since hardware multipliers 
are plentiful on the SmartFusion2. A final FIR 
rate converter shapes the signal up to LOMSPS. 
The FIR’s coefficients are software controllable. 
The reverse flow happens on a receive. 

The modem consists of both a modulator for 
the transmitter, and a demodulator for the re- 
ceiver. I’ve sketched out a modem for AM, FM, 
SSB, and FSK, but I have not finalized the de- 
sign. The full modem will sit in the smallest Mi- 
crosemi FGPA with the digital signal converter 
by intelligently sharing the hardwired multiplier 
resources. 

I gave the Sunday Seminar at the TAPR DCC 
2014 on the concept of System on a Chip Field 
Programmable Gate Arrays. If you want to cover 
the basics, I recommend you check out the four 
hours of footage up on YouTube. 

Since the FPGA is firmware, and it can be re- 
programmed in the field, it’s important to have 
the right tools to help build the machinery in 
the FPGA. I have spent a lot of energy on using 
completely free and open tools to do all of the 
design validation. 


The flow previously has been to use Python to 
describe the register transfer logic using a sub- 
set of the language and the MyHDL library{13]. 
This has turned out to be really valuable, as it 
makes generating complex Verilog modules much 
more streamlined. You can use object oriented 
constructs in Python to help efficiently describe 
the design. 


The easiest way to do simulations is to co- 
simulate between Python and an Open Source 
verilog simulator, like Icarus Verilog|14]. This 
works pretty well, but it is not efficient at all. 
As the modem gets more complex, the simula- 
tion times grow, and it gets harder and harder 
to properly design the modem. 


I am now using an additional tool - 
Verilator{15].  Verilator takes the final Verilog 
code, and converts it into a C++ class. Oper- 
ating at the bare metal has given me a full 100x 
improvement in speed. Its not an Apples to Ap- 
ples comparison, but at the end of the day us- 
ing the new tool flow you can much more quickly 
and iteratively design new signal processing flow- 
graphs in the FPGA. 


5 Conclusion 


The problem of building a completely self- 
contained, portable software defined radio has 
been explored. The evolution of the hardware 
was documented over the three years of develop- 
ment. The details of the hardware for the most 
recent prototype were presented. The user inter- 
face and developer software stacks were covered. 
Finally, the digital signal processing firmware op- 
timizations were discussed. 


There are many sub-problems to explore as 
the hardware, software, and firmware continue 
to evolve and mature into a state that we all can 
use in the field. If you’re interested in helping 
out in any way, contact me, visit my website|16], 
and get involved! 
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